Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000145_owner-urn-ietf _Thu Oct 31 14:59:14 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18846 for urn-ietf-out; Thu, 31 Oct 1996 14:59:14 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18841 for <[e-mail]>; Thu, 31 Oct 1996 14:59:10 -0500
Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA27671  (mail destined for [e-mail]); Thu, 31 Oct 96 14:57:53 -0500
Received: from carlyle.ncsa.uiuc.edu (carlyle.ncsa.uiuc.edu [141.142.230.144]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id NAA16767; Thu, 31 Oct 1996 13:56:41 -0600
Received: from ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by carlyle.ncsa.uiuc.edu (8.6.11/8.6.9) with ESMTP id NAA29904; Thu, 31 Oct 1996 13:56:40 -0600
Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id NAA10608; Thu, 31 Oct 1996 13:51:04 -0600 (CST)
Date: Thu, 31 Oct 1996 13:51:04 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail] (Leslie Daigle)
Cc: [e-mail]
Subject: Re: Names and Locations (was [URN] some comments)
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Leslie Daigle writes:
 > > In general, each scheme, whether for a URL or URN, should be
 > > associated with some resolution protocol.
 >
 > I'm not sure I'm clear on what you're getting at here, and even if
 > we do agree, I think there is some potential for the above to be a
 > bit misleading.

I'll try to be more clear below.  If URLs and URNs are to be in the
same name space of URI schemes, then we need to talk about them as the
same kind of thing.  This is not only possible, it is correct.

BTW, emphasis in the following is not shouting.  I'm very calm, now.

 > The point of the indirection in the URN naming is to abstract the
 > (final) resolution protocol so that no name space is specifically
 > associated with, say, HTTP, or Whois++.  THe idea is that any URN
 > can be resolved using different protocols -- at one time, or at
 > different stages in its lifetime -- and this is a separate process
 > from determining the URN identifier string.

This illustrates why I think the term "resolution protocol" is
confusing.  I mean something different than you and others do - and
you qualified it parenthetically by saying "the (final) resolution
protocol".  More below.

 > However, there is a general mechanism for handling URNs to the
 > extent of extracting Naming Authority, etc etc etc, which is
 > standard across the URNs we define here.

My point is that this mechanism for looking up the naming authority
etc, as defined by the NAPTR spec (or other such specs), is only
*part* of the WHOLE RESOLUTION PROCESS.  (Calling it a "resolution
process" may avoid the "protocol" issue, but it is not that simple, as
I argued in previous mail.)  The first part of the whole resolution
process involves how you talk to DNS servers to lookup the naming
authority etc.  Note: HOW YOU TALK TO DNS IN THIS PARTICULAR WAY *IS*
A PROTOCOL.  If you like, it is a protocol layered on top of the raw
DNS protocol.  Note also that it is this lookup process that makes
URNs into locations; You LOOK UP URNs starting AT A PARTICULAR
LOCATION which is the root of the name space (urn.net or wherever).
(Actually, just as for URLs, you can lookup up the very same URNs
in different ways - see below.)

Another part of the process is using the result of the first part,
specifically the list of what is being called "resolution protocols".
The client may then select one of these "resolution protocols" to
continue with the resolution process.  But note that this is not
necessarily the end of the whole process.  A resolution service might
return an indirection to yet another URI, so the resolution process
continues until you have what you want, whether that is the resource
originally identified or some information about it, or you get an
error.

There may be other parts of the resolution process that are used
*before* looking up naming authorities, such as trying to resolve
the whole identifier from a local cache, or from a more global cache.
It may not be necessary to do some of the above steps in the resolution
process depending on what is found elsewhere via other protocols.

Many protocols are involved in this whole resolution process, and to
say that only some are the "resolution protocols" obscures the truth
and so is misleading.

 > > You made the curious statement that URNs identify resources while URLs
 > > identify locations.  I'm not sure whether that was a slip, but to my
 > > mind, a URL *IS* a location that identifies a resource.  Now you also
 >
 > URLs identify a particular location for a resource.

OK, what is a location?  Is it the bits on the disk that "has" the
resouce?  (The disk might be shared by many servers, so the resource
has a different "location" for each server.) Is it the server running
at a particular IP address and port, that may share many disks with
other servers?  (The server may be a virtual server that runs on many
machines, and the particular IP address is irrelevant.)  Is it the
domain name of the server, together with the path within the server?
That's getting closer to the abstraction that URLs provide.  Is the
location, in fact, the URL itself?

Consider caches.  The resolution of a URL via a cache proxy may find
the resource in the cache rather than in some remote server.  What is
"the location" of the resource in that case?

Here is an example of how what is thought of as a location really
turns out to *be* a name (as in persistent location).  Take a normal
http URL such as http://www.ncsa.uiuc.edu/.  Instead of using normal
HTTP to resolve the URL, or to look it up in a cache, let's set up a
NAPTR-based "http" naming authority.  Under that branch of the name
space, we could ask the appropriate DNS server to look up
'www.ncsa.uiuc.edu' to find out where a server is currently located
and what "resolution protocols" are currently supported.

We don't need to create a new kind of identifier to make a URL into a
persistent location.  We *do* need new persistent services, such as
the NAPTR records in DNS.

How a URL is processed determines where the resource is really found,
and the very same URL could be processed many different ways and the
resource found many different places.

And besides all that, a URL can be used to find other things
associated with the resource, by completely different means, such as
annotations or censorship ratings.  The URL identifies all those
things too, depending on how the URL is processed.

The tight binding between http URLs and the HTTP protocol is an
illusion created by frequent reinforcement and a transparent
resolution process.  (Similarly, many people feel they "visit" a web
page, rather than bring a copy of the page back to their browser.)

To summarize, both URLs and URNs have the following abstract
resolution process in common:

1. Do some client-specific processing of the URI - maybe end there.
2. Look at the scheme name of the URI.  If it says "URN:" drop it and repeat.
3. Look up the scheme in local table to find out what process should
   be invoked.  E.g. news URIs may use NNTP, http URIs may use HTTP,
   cid URIs may use NAPTR-protocol.
4. Invoke the process identified by step 3.
5. If error results, exit.
6. If redirected to another URI, repeat whole process with that URI.

An alternative to steps 2 and 3 would use more than just the scheme
name to determine what process to invoke.  There are several other
varients possible in the whole process, and each client or each user
might do things differently.

I hope I've made my postion very clear regarding names, locations, and
the resolution process.

--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/